iT邦幫忙

DAY 22
3

30天快速上手TDD系列 第 22

[Day 22]ATDD - ATDD的循環

  • 分享至 

  • xImage
  •  

上篇文章簡單扼要的說明了,如何透過驗收測試案例,來輔助驗證user story是否已經完成。

也強調了驗收測試案例的基本feature,該由哪些共同協同合作撰寫,以及這麼做的目的和好處。

接著這篇文章,則是要說明一下在軟體開發流程中,使用ATDD來進行的循環與過程。

上一篇文章:[Day 21]ATDD - Acceptance Testing
本系列文章專區
@前言
TDD可以讓開發人員用小步伐的節奏慢慢累積可正常運作,且符合開發人員預期的程式碼。但ATDD關注的不一定是技術層面的事,而是在功能層面上確保「這個working software是否真的符合了使用者的需求」。

一開始透過user story抽象地定義使用者的需求,再依據如何定義user story已經完成,來break down成驗收測試案例。

有了驗受測試案例之後,我們才會開始著手建立一個可行走的骨架(Walking Skeleton),也就是先定義好使用者要什麼,才會明白系統或功能要怎麼撰寫。

定義好最後要怎麼通過驗收測試,才代表撰寫完成的系統或功能符合最終的需求。

@ATDD的循環
先前有稍微提到TDD的循環,如下圖所示:

圖片來源:http://reddevnews.com/articles/2007/11/01/testdriven-development-tdd.aspx

ATDD以概念來說,循環可以先簡化成下圖的方式:

前提當然是user與PO, 測試人員先擬定好了user story(若在Scrum中,可能是PO依照sprint backlog來定義對應的user story),接著按照四個步驟的循環來進行:

  1. 挑選一個user story
  2. 撰寫驗收測試案例
  3. 自動化測試
  4. 撰寫實際功能內容

跟TDD很像,不是嗎?接下來我們針對這四個步驟來進行說明。

@挑選一個user story
怎麼挑選一個合適的user story,這在實務上的眉角也很多,有興趣想深入了解的讀者,一樣請去讀Mike Cohn的User Stories Applied,筆者這邊只列出最簡單的原則:根據priority來選擇

前面兩篇文章有提到,user story通常上面要記錄幾個東西:

  1. user story內容
  2. priority
  3. 負責人
  4. 驗收測試案例

註:user story通常由sprint backlog而來,sprint backlog由product backlog而來。

user story在設計時,通常也有許多原則要遵循,例如:INVEST model

INVEST指的是:

  1. I – Independent(獨立)
  2. N – Negotiable(可修改)
  3. V – Valuable (對使用者有價值)
  4. E – Estimable (可評估範圍)
  5. S – Small (夠小)
  6. T – Testable (可測試)

而滿足了這些原則,就會減少一些實務上挑選user story綁手綁腳的問題發生。(例如user story的相依性,影響到挑選的順序)

@撰寫驗收測試案例
如同上一篇文章:[Day 21]ATDD - Acceptance Testing所提到的,用user story card記錄user story,可以在其背面記錄驗收測試案例,由PO(user), 測試人員與開發人員一同撰寫。

只專注在要測試的幾件事,也就是完成user story需要達成的幾件事。注重What,不注重How。建議可以透過一些工具輔助,以降低使用者或PO抗拒,並減少未來轉換成測試程式的成本,如文末的**@ATDD工具段落**。

@自動化測試
我們定義好需求之後,就是定義怎麼樣叫做完成需求。所以撰寫測試來驗證,功能是否符合預期。測試寫好之後,才來填肉,目標就是讓系統的程式碼通過測試。

簡單的說,除非測試案例寫錯,否則程式碼只要通過測試,就代表它是對的、是符合最終使用者的需求。這也是為什麼驗收測試案例需要各個角色的參與。

@撰寫實際功能內容
為了要先滿足驗收測試案例,通常系統面的工作會先浮現出來,例如:

  1. prototype:
    我們需要一個prototype,而且這個prototype可以讓使用者認同與驗收。它是一個working software,即使不完全,也可以表達出user story所需要的功能。

  2. 環境:
    可能需要有測試機、測試DB、測試資料、測試file server、模擬的外部服務、介接的系統介面、使用的協定與資料格式。

這一些東西會被強迫在系統剛開始建置時,程式碼撰寫之前,一一浮上檯面。

這些東西在許多瀑布式或是一般專案中,可能都會等到程式碼開發完成才開始進行,但那時倘若出現一些差錯,都可能導致整個程式碼需要重新翻修。

透過ATDD,第一步就是先建立可行走的骨架,在撰寫任何程式碼之前,先確定環境建置,該透過模擬的元件或服務,系統的邊界,都會先被確定下來,以避免未來異動風險過高,或是不符合使用者需求的情況發生。

接著由user story整理出驗收測試案例,透過驗收測試案例產生整合測試案例,透過整合測試案例產生單元測試案例,一環扣著一環,top-down的往下設計下去,目標都是符合最終使用者的需求。填肉的過程則是有點bottom-up,但那無所謂,因為填肉的過程目標明確,每一塊肉,就是為了滿足某個測試案例而存在。

最終,原本的V-model就會演化成W-model,如下圖所示:

圖片來源:http://www.testingthefuture.net/2009/09/the-w-model/

@User Story與ATDD
在Scrum的過程中,整個團隊在累積開發進度時,都是透過user story為單位來確認進度。把ATDD放在整個Scrum的sprint中,就如下圖所示:

圖片來源:http://www.methodsandtools.com/archive/archive.php?id=72p9

筆者一直在強調節奏,在Scrum的Sprint中,user story與ATDD的節奏就是:

  1. 挑一個user story
  2. 撰寫user story的驗收測試案例
  3. 建立自動化測試程式
  4. 完成user story
  5. 挑下一個user story

@ATDD與TDD的關係
了解了Scrum的流程後,而ATDD與TDD的關係,用下面這張圖來表示,再清楚不過了:

圖片來源:http://www.methodsandtools.com/archive/archive.php?id=72p9

  1. 先撰寫user story
  2. 為user story撰寫驗收測試案例
  3. 撰寫驗收測試程式
  4. 驗收測試結果失敗
  5. 撰寫整合測試案例
  6. 整合測試結果失敗
  7. 撰寫單元測試案例
  8. 單元測試結果失敗
  9. 撰寫實際程式
  10. 通過單元測試
  11. 重構單元測試涵蓋的範圍
  12. 重複step7~step11,直到整合測試通過
  13. 重複step5~step12,直到驗收測試通過
  14. 重複step3~step13,直到user story上的驗收測試案例全數通過
  15. user story完成,挑下一個user story

@Scrum流程的輔助
這樣可以在整個軟體開發的流程,讓整個團隊有著一定的節奏(這也是Scrum這個framework會定義一些固定的軟體開發流程的原因),這裡補上Scrum的流程圖:

圖片來源(by Ruddy Lee):http://ruddyblog.wordpress.com/2011/04/03/scrum-%E8%AA%B2%E7%A8%8B%E5%9C%96%E7%A4%BA/

透過Scrum流程的輔助,來幫助每個角色在整個軟體開發流程中,各階段擁有一定的節奏。透過user story與ATDD的方式,讓開發人員與測試人員維持一定的節奏。透過ATDD與TDD與重構,讓開發人員在撰寫實際的功能程式碼時,也可以維持一定的節奏與品質。

有了節奏,有了測試的保護,就可以快速小步前進,持續回饋,持續演進,而且能夠更客觀的預估團隊的產出進度,且可以凝聚團隊向心力,建立信任基礎,這就是整套Scrum預期達到的效果。

@小結
就開發團隊來說,開發流程就如下圖所示,一環扣著一環:

從user story開始,觸發ATDD,觸發TDD,觸發重構。

每一個環節,都是下一個環節的基礎。透過許多工具或開發方式,來降低每一個環節之間的轉換成本,讓每一個環節、每一個角色,最終目的都是產生一個最符合使用者需求的系統成品,這樣才是一個成功的軟體開發。

@ATDD工具
這邊補充一下幾個常見的ATDD工具 (筆者比較喜歡表格式的呈現):

  1. Fit:官網
  2. FitNeese (像Wiki的Fit):官網
  3. Selenium: 官網,也可以參考前面的修煉文:[Day 8]Integration Testing & Web UI Testing

這一系列會先以Selenium為主,當然還是可以輔以Fit或FitNeese來協助user或PO定義驗收測試案例。

如同前面修煉文內容所示,透過Selenium可以幫助開發人員建立後續的自動化測試程式。


上一篇
[Day 21]ATDD - Acceptance Testing
下一篇
[Day 23]BDD - Introduction
系列文
30天快速上手TDD31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

2 則留言

0
ted99tw
iT邦高手 1 級 ‧ 2012-10-30 16:45:28

推!推!推!推!推!
讚讚讚

是說每隻加菲貓都這麼厲害嗎?毆飛

就是91 iT邦研究生 4 級 ‧ 2012-10-30 18:27:39 檢舉

請認明有 91® 正字標記的,才是正牌的!

0
pajace2001
iT邦研究生 1 級 ‧ 2012-11-01 10:31:31

這個沒有91®

意思是,這是盜版的~這是盜版的
踹共踹共

我要留言

立即登入留言